It is often useful to describe the behavior of a system having discrete states (such as a digital computer) in terms of a finite state machine model. A finite state machine model is described in terms of “states,” “transactions,” and “events.” At any given time, one or more of the states of the machine is said to be “active.” Actions within the model are triggered in response to the occurrence of “events” which are defined by the model. When an event occurs, it may trigger an action associated with a particular state, or it may trigger a change in state. State changes in response to events are determined by a set of defined “transitions,” which indicate that a change from one state to another should occur in response to an event when particular conditions are true. Such models are therefore said to be “event-based”.
One well-known formalism for representing finite state machines is called “statecharts.” See D. Harel, “Statecharts: A Visual Formalism for Complex Systems,” Sci. Computer Prog., July 1987, pp. 231-274. In a statechart, a finite state machine is graphically represented as a connected graph having a set of nodes, representing states, connected by directed edges, representing transitions. The existence of an edge going from a first node to a second node in a statechart indicates that a transition may occur between the respective states represented by the two nodes when conditions associated with the edge are met.
A variant of the statechart formalism is used in connection with the Stateflow® programming system developed by and available from The Mathworks, Inc., Natick, Mass. The Stateflow® modeling system permits a user to input a statechart-like diagram describing a finite state machine using a graphical user interface. The diagram is then converted by the Stateflow® system into source code in a procedural programming language such as C.
Referring now to FIG. 1, an example of a finite state machine 100 in a Stateflow® diagram is shown. States 105 include labels 110, followed by a sequence of statements in the Stateflow® action language. These statements describe actions that may be performed by the finite state machine when an event occurs. The statements may include “entry actions” 120, “during actions” 130, and “exit actions” 140. During emulation of finite state machine 100, “entry action” 120 is performed each time state 105a becomes active, “during action” 130 is performed whenever an event occurs and state 105a is active, and “exit action” 140 is performed whenever state 105b becomes inactive. One type of “during action” is a “conditional action” 150 (specified by the prefix “on”). “Conditional action” 150 includes a conditional expression 160 followed by a “:” followed by an action statement 170. Action 170 of conditional action 150 is performed whenever an event occurs, state 105a is active, and conditional expression 160 is true. (Here conditional expression 160 is the name of an event, “power_outage”, which is true whenever that event has just occurred).
Referring now to FIG. 2, a generic example of a transition definition 200 connecting two states 205 and 210. in a Stateflow® diagram is shown. The transition may include a conditional expression 215, optionally followed by a condition action 220, and/or a transition action 230. Whenever an event occurs and state 205 is active, the conditional expression 215 is evaluated. If it is true the condition action 220 is performed. Then state 205 is made inactive, transition action 230 is performed, and state 210 is made active. Here, conditional expression 215 is “E[off_count0]” which is true when event E has occurred and the variable off count equals zero. It is followed by a condition action 220 “off_count+” which results in incrementing the variable off count by one. The tansition action 230 “Light_off” indicates that a Light_off event should be broadcast when the transition is complete.
States in a Stateflow® diagram may include substates. A state that includes substates is said to be a superstate of those substates. A substate may only be active when its superstate is also active. Two types of superstates may be specified by a user in a Stateflow® diagram. In an “exclusive or” superstate only one of its substates may be active at any given time. In a “parallel” superstate, more than one substate may be active at the same time.
When the Stateflow®D modeling system generates code for emulating the finite state machine in a diagram, it generates, for each state in the diagram, code for performing the state's entry, during, and exit actions, as well as logic for executing these code fragments at appropriate times according to the semantics of the state diagram. For each transition in the diagram, the system generates code for testing the condition associated with the transition and for performing appropriate actions associated with the transition if the condition is true. These actions include calling the exit actions procedure for the state being exited, and the entry actions procedure for the state being entered.
In creating finite state machine models, it is often useful to condition a particular transition or action statement on the number of times that an event has occurred since the system entered a particular state. For example, it may be useful to transition from a first state to a second state on the condition that a particular event has occurred five times since the first state became active. We refer to such conditions as “temporal conditions.”
In prior art systems, it was possible for a user to describe a finite state machine having temporal conditions by explicitly setting up a counter variable and including explicit action statements in a particular state to initialize, increment and test the counter variable whenever a particular event occurred. However such techniques were error prone and resulted in inelegant and awkward block diagram descriptions.